今天講 ERM (實體關係模型)~

這已經脫離純前端的範疇，進入到軟體架構的領域。但前端也是軟體的一部分，從它開始往後延伸，有 API (前後端接口)、後端語言(從這邊開始往後都是後端範圍)、資料庫查詢語言( SQL )、資料庫...，而後端的基礎正是 ERM。

ERM 沒有確定下來，資料庫不能建、SQL 不能寫、後端語言拉不到資料，整個後端可說被掏空。沒有後端，前端徒有表面，沒有功能。ERM 的重要性可想而知。

至於什麼是 ERM，直接進例子吧！假設今天要為這樣一個甜點電商網站(設計者: 六角學院)建立 ERM，步驟如下：

• 找出實體
• 定義屬性
• 找出關係
• 正規化

我們一個一個來看吧~

1.找出實體(Entity)

實體代表網站中真實的個體，這個甜點電商中，我們很快地發現有登入頁面，所以有會員，另外當然就是甜點和訂單。

搭配 ERM 圖形：

2.定義屬性

如果說實體是名詞，那屬性就是形容詞了。屬性會搭配值，例如會員的 Email 屬性是"example@email.com"、某甜點的價格屬性是"NT$ 90"。

ERM 圖形：

3.找出關係型態

找出有關係的實體，例如會員和訂單、訂單和甜點。然後辨別這兩個實體是以下什麼關係類型：一對一、多對一、一對多、多對多。以下是 ERM 中代表的符號：

1:一
*:多
0..*:零到多(會員擁有0-張訂單)
1..:一到多(訂單有1-*種甜點)

例如，會員可以下訂多張訂單，但是一張訂單只屬於一個會員，所以我們會這樣說：會員對訂單是一對多關係，訂單對會員是多對一關係。

ERM 圖形：

4.消除多對多關係

多對多關係會造成資料庫混亂，必須要在兩者之間再拆出一個實體出來。

例如，我們發現訂單和甜點之間是「多對多」關係，也就是一張訂單可以包含多種甜點，而某種甜點也可能在多張訂單中出現，試想，要如何在「訂單」中紀錄購買了甚麼甜點以及其數量呢？

• 如果屬性是甜點，值是一個這樣的陣列：["馬卡龍","甜甜圈", ...]，那數量要記錄在哪裡？且資料庫通常是不會放二維資料的。
• 又如果屬性是"馬卡龍"，值是數量，那第二種甜點要再增加另一個屬性嗎？那這樣不同訂單的屬性可能數量不同，根本無法放在同一張表格當中。

為了解決以上多對多造成的問題，我們需要多一個「訂單明細」，訂單明細需要「訂單編號」作為與「訂單」之間的聯繫，然後逐一記錄各種甜點和其訂購數量。

ERM 圖形：

這樣，就完成一個最、最簡單的 ERM 模型(但並沒有完全完成這份設計稿提出的需求，或許之後找機會完成)。而就算都是電商網站，其 ERM 並不會完全一樣，因為一切依需求而定，可能這家網站的會員有 Email 屬性，別家沒有。所以在製作 ERM 之前，更重要的是將需求訪談清楚。

以上，深知自己的解釋力還不到位，如果想到更好的解釋方法，會再回來補強補強。明天會談 ERM 與資料表之間的關聯~